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Abstract 

Inductive datatypes provide mechanisms to define finite data such 
as finite lists and trees via constructors and allow programmers 
to analyze and manipulate finite data via pattern matching. In 
this paper, we develop a dual approach for working with infinite 
data structures such as streams. Infinite data inhabits coinductive 
datatypes which denote greatest fixpoints. Unlike finite data which 
is defined by constructors we define infinite data by observations. 
Dual to pattern matching, a tool for analyzing finite data, we de- 
velop the concept of copattern matching, which allows us to syn- 
thesize infinite data. This leads to a symmetric language design 
where pattern matching on finite and infinite data can be mixed. 

We present a core language for programming with infinite struc- 
tures by observations together with its operational semantics based 
on (co)pattern matching and describe coverage of copatterns. Our 
language naturally supports both call-by-name and call-by-value 
interpretations and can be seamlessly integrated into existing lan- 
guages like Haskell and ML. We prove type soundness for our lan- 
guage and sketch how copatterns open new directions for solving 
problems in the interaction of coinductive and dependent types. 

Categories and Subject Descriptors D.3.3 [Programming Lan- 
guages] : Language Constructs and Features — Data types and struc- 
tures, Patterns, Recursion; F.3.3 [Logics and Meanings of Pro- 
grams •]: Studies of Program Constructs — Program and recursion 
schemes, Type structure 
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1. Introduction 

Representing and reasoning about infinite computation plays a cru- 
cial role in our quest for designing and implementing safe soft- 
ware systems, since we often want to establish behavioral proper- 
ties about our programs, reason about I/O interaction and processes, 
and establish liveness properties that eventually something good 
will happen. While finite structures such as natural numbers or fi- 
nite lists are modelled by inductive types, infinite structures such 
as streams or processes are elegantly characterized by coinductive 
types. Inductive types are now very well understood and supported 
by functional languages and proof assistants, whereas the theoreti- 
cal foundations and practical tools for coinductive types lag behind. 

For example, in the Calculus of (Co)Inductive Constructions, 
the core theory underlying Coq [INRIA 2010], coinduction is bro- 
ken, since computation does not preserve types [Gimenez 1996; 
Oury 2008]. In Agda [2012], a dependently typed proof and pro- 
gramming environment based on Martin Lbf type theory, inductive 
and coinductive types cannot be mixed in a compositional way. For 
instance, one can encode the property “infinitely often” from tem- 
poral logic, but not its dual “eventually forever” [Altenkirch and 
Danielsson 2010]. 

Over the past decade there has been growing consensus [Set- 
zer 2012; McBride 2009; Granstrom 2009] that one should distin- 
guish between finite, inductive data defined by constructors and in- 
finite, coinductive data which is better described by observations. 
This view was pioneered by Hagino [ 1987] who modeled finite ob- 
jects via initial algebras and infinite objects via final coalgebras 
in category theory. His development culminated in the design of 
symML, a version of ML where one can declare codatatypes via a 
list of their destructors [Hagino 1989]. For example, the codatatype 
of streams is defined via the destructors head and tail which de- 
scribe the observations we can make about streams. Cockett and 
Fukushima [1992] took up his work and designed a language Char- 
ity where one programs directly with the morphisms of category 
theory. But while Charity was later extended with pattern match- 
ing on (initial) data types [Tuckey 1997], no corresponding dual 
concept was developed for codatatypes (called final data types in 
Charity). 

In this paper, we take a first step towards building a type- 
theoretic foundation for programming with infinite structures via 
observations. Dual to pattern matching for analyzing finite data, 
we introduce copattern matching for manipulating infinite data and 
describe coverage for copatterns. In order to focus on the main 
concepts and avoid the additional complexities that come with 
dependent types, for instance, the need to guarantee termination 
or productivity, we confine ourselves to simple types in this article. 


Our theoretical treatment of patterns and copattems takes in- 
spiration from the growing body of work which relates classical 
and linear logic to programming language theory via the Curry- 
Howard-Isomorphism; more precisely, we build on the duality be- 
tween (finite) values as right-hand side proof terms and continua- 
tions or evaluation contexts as left-hand side terms of sequent cal- 
culus [Curien and Herbelin 2000; Wadler 2005; Kimura and Tat- 
suta 2009], Following Zeilberger’s [2008b] deep analysis of fo- 
cused proofs in linear sequent calculus [Andreoli 1992] and its 
relationship to pattern matching and evaluation order in program- 
ming languages, we distinguish between positive types which char- 
acterize finite data and negative types which describe infinite data. 
While values are matched against patterns, evaluation contexts are 
matched against copatterns. Our notion of copatterns extends pre- 
vious work by Licata, Zeilberger, and Harper [2008] to treat least 
fixed-points as positive types and greatest fixed-point as negative 
types, and we recognize copatterns as a definition scheme for infi- 
nite objects. 

More precisely, we regard copatterns as experiments on black- 
box infinite objects such as functions, streams and processes. Infi- 
nite objects can be defined by a finite, covering set of observations, 
which are pairs of experiment (copattern) together with its outcome 
(defining term). We take the distinction between the finite / initial 
/ positive and the infinite / final / negative serious and give intro- 
duction rules and patterns for the former and elimination rules and 
copatterns for the latter. This leads to a core functional language 
based on natural deduction instead of the sequent calculus formu- 
lation explored in by Zeilberger [2008b] et al. [Licata et al. 2008]. 
Our contributions are the following: 

1. We show how copatterns complement the syntax of existing 
functional languages and enable a style of programming with 
infinite objects by observations (Section 2.2). There is no need 
to move to a different programming paradigm such as classi- 
cal logic [Curien and Herbelin 2000; Wadler 2003] or the mor- 
phisms of category theory (Charity). 

2. We describe a non-deterministic algorithm for checking copat- 
tern coverage and prove that well-typed and complete programs 
do not go wrong (Section 5). The construction of a covering 
set of copatterns corresponds to the interactive construction of 
a program as in Agda and Epigram (Section 2.1). 

3. We explain how copatterns can be a fruitful paradigm in rewrit- 
ing and dependent type theory. In rewriting , definition by ob- 
servations lead naturally to strongly normalizing rewrite rules 
and a semantics without infinitary rewriting [Kennaway and 
de Vries 2003] (Section 2.3). In dependent type theory, they 
overcome the subject reduction problem of the Calculus of 
(Co)inductive Constructions [Gimenez 1996] (Section 2.4). 

The remainder of this article is structured as follows: We infor- 
mally describe copatterns in Section 2 and explain in detail their 
benefits in programming, rewriting and type theory. In Section 3, 
we define formally our core language with copatterns and its static 
semantics. We then describe its operational semantics together with 
copattern matching in Section 4. Coverage of copatterns together 
with the type safety proof is presented in Section 5. We briefly de- 
scribe a prototype implementation of copatterns for Agda in Sec- 
tion 6, before we conclude with a discussion of related work (Sec- 
tion 7) and an outlook to further work (Section 8). 

2. Copatterns and Their Applications 

In this section we explain copattems (Section 2.1) and flesh out 
the arguments started in the introduction. We illustrate how copat- 
terns impact functional programming (Section 2.2), rewriting (Sec- 
tion 2.3), and dependent type theory (Section 2.4). 


2.1 From function definition to copatterns 

We introduce copatterns in the scenario of interactive program 
construction by refining the left hand side of a function definition 
step by step. As we will see, copatterns arise naturally as the 
generalization of definition by pattern matching. 

As an example, we construct the infinite stream N,N — 
1, . . . , 1, 0, N, N — 1, . . . , 1, 0, . . . of natural numbers via an 
auxiliary function cycleNats : Nat — > Stream Nat such that 
cycleNats n = n, n — 1, . . . , 1, 0, N, N — 1, . . . , 1, 0, . . . . 

Before we begin, let us define Stream Nat as a recursive record 
type containing the possible observations we can make about 
streams. These observations are also referred to as destructors, 
since they allow us to take apart streams. 

record Stream A = { head : A, 

tail : Stream A } 

Now we will construct cycleNats step-by-step, similar to the 
interactive editing in Agda [Norell 2007] and Epigram [McBride 
and McKinna 2004]. The starting point is the template: 

cycleNats : Nat — t Stream Nat 

cycleNats = ? 

Since a function is an infinite object, we define it by observation 
rather than giving its value (a A-abstraction) directly. However, 
we cannot give a value of cycleNats n for every natural number 
n, instead, we apply cycleNats to a generic natural number, the 
pattern variable x. 

cycleNats* = ? 

Application to x, which we write as • x, is our first instance of a 
copattern, an applicative copattern. It is, in this case, a generic ex- 
periment on cycleNats. The observation of its outcome determines 
cycleNats. 

We are left with the task of constructing a Stream of natural 
numbers. We can make two principal experiments on a stream: 
we can observe its head and its tail, and the outcome of these two 
experiments determines the stream. These experiments give us two 
new copatterns: head ■ and tail •, called destructor copatterns , and 
lead to the next refinement of our definition of cycleNats: 

head (cycleNats x) = ? 

tail (cycleNats *) = ? 

The observed head of cycleNats x is just x. To determine the tail, 
we need to split on the pattern variable *: 

head (cycleNats x) = x 

tail (cycleNats 0) = ? 

tail (cycleNats (1 + x')) = ? 

This generalizes the applicative copattem form • x to • p where p 
is a pattern , as usual, a term built from constructors, literals, and 
uniquely occurring variables only. We finally can fill the remaining 
two holes and complete our definition of cycleNats: 

head (cycleNats x) = x 

tail (cycleNats 0) = cycleNats N 

tail (cycleNats (1 + *')) = cycleNats*' 

The infinite object cycleNats, a function yielding streams, is de- 
fined via the complete set of copattems (head (■ *), tail (■ 0), 
tail (■ (1 + *'))} where •, the hole, is a placeholder for the function 
cycleNats. It is determined by the following set of observations, 
i. e., experiments mapped to their results: 

head (■ *) K ► * 

tail (■ 0) i — t cycleNats N 

tail (■ (1 + *')) i — ^ cycleNats *' 


2.2 Copatterns in functional programming: Restoring a 
missing symmetry 

Destructor copattems are a useful addition to functional languages 
even if no coinduction is involved. In the following we evolve an 
implementation of the state monad typical for Haskell to demon- 
strate why the absence of general copattems breaks symmetry, and 
how copatterns restore it. 

A first implementation defines the type State S A of a stateful 
computation with result A just as a synonym for S — > (A x S). 
The monadic operations return and ^>= (“bind”) are given in an 
applicative style. 

State S A = 

return : 

return as = 

_»=_ : 

(m k) s = 


S^AxS 

A — > State S A 
(a, s ) 

State S A — > {A — > State S B) — > State S B 
let (a, s') = m s in k a s' 


Returning a in state s yields the pair (a, s) of result and unchanged 
state, and executing the sequence m ~^>= k in state s first executes 
m : State S' A in state s, resulting in a value a : A and a new 
state s', in which we run the continuation k applied to a. The code 
explains itself nicely if the application to s is read as in state s. 

There are reasons to move away from type synonym State S A 
to a bijection between the monadic type State S A and its im- 
plementation as S — > A x S. For instance, in Haskell, type syn- 
onyms interact badly with type-class based overloading, and in- 
stead, State S A is implemented as a single-field record type with 
projection runState and constructor state. 

record State S A = state{runState : S — > A x S} 
runState : State SA->S->ixS 

state : (S — > A x S) — > State S A 


As we update our implementation of the monad operations, we are 
in for an unpleasant surprise: We can only partially keep up the 
applicative style, more precisely, only on the right hand side of 
=, the expression side. Here, we only have to prefix the monadic 
values m and k a with the projection runState. But on the left 
hand side, the pattern side, we cannot do the same change, since 
projections are not allowed there. Instead we have to turn the l.h.s. 
application to s to a r.h.s. A-abstraction over s, and prefix it with 
constructor state. 


return 
return a 


_»=_ 
m ~^>= k 


A — x State S A 
state (As. (a, s)) 

State S A — x [A —y State S B) — > State S B 
state (As. let (a, s') = runState m s 
in runState ( k a) s') 


The projection bits are still nice to read, e. g., runState m s reads 
as run m in state s, however, the definition of m ^>= k as the 
stateful computation, that if you pass it state s, ... is a bit bumpy. 
The symmetry is broken. 

Copattems, which allow projections also on the l.h.s., restore the 
symmetry and allow a smooth definition of the monad operations 
again. 


return 

runState (return a) s 


A — > State S A 

{a, s) 


_>=_ 


runState (m ^>= k) s 


State S A 
{A ->■ State S B) 

State S B 

let (a, s') = runState m s 
in runState ( k a) s') 


It reads if you run return a in state s, you get (a, s); and to run 
m k in state s, run m in s, obtaining a value a and a new 
state s in which you run k a. 

2.3 Deep copatterns in rewriting: Strong normalization for 
corecursive definitions 

In the following we argue that copatterns help to integrate infinite 
objects into term rewriting, without having to change the standard 
reduction semantics. 

A popular example of programming with infinite objects is the 
creation of the stream of Fibonacci numbers. It is concisely defined 
as 

fib = cons 0 (cons 1 (zipWith fib (tail fib))) 

Herein, cons is the stream constructor, head and tail the projection, 
and zipWith _+_ yields a stream by applying addition pointwise 
to a pair of streams (here: fib and tail fib). 

Clearly, reading this equation as a rewrite rule, the computation 
of fib does not terminate under the standard semantics, which is 
rewrite when the left hand side matches. Using infinitary rewriting 
[Kennaway and de Vries 2003], fib converges to the Fibonacci 
stream 

cons 0 (cons 1 (cons 1 (cons 2 (cons 3 (cons 5 . . . 

However, we are interested in the strong normalization of a term 
rewriting system since this yields a decision procedure for equality 
(which then implies decidability for checking dependent types). 

We can revert to a non-standard rewriting semantics: label the 
definition of f i b as corecursive and only unfold it when its value is 
demanded, e. g., by a projection. This solution, for instance taken in 
Coq [Gimenez 1996], does not help with our particular definition 
of fib either, since tail fib appears in its own unfolding, leading 
to infinite reduction. A workaround exists: we could introduce a 
mutually defined auxiliary stream fib' which denotes the tail of fib. 

But copatterns provide a principled and scalable solution. Me- 
chanically, transforming the definition of fib into copatterns yields 

head fib = 0 
head (tail fib) = 1 

tail (tail fib) = zipWith _+_ fib (tail fib). 

These equations are actually fulfilled by our first equation for fib, 
but now we take them as definition of fib. The rewrite system is 
terminating; neither fib nor tail fib can be reduced by itself because 
none of the three defining copattems matches. 

Our syntax allows us to delay unfolding of corecursion until 
the whole copattern is matched. Copatterns, in particular, deep 
copatterns such as nested projections tail (tail •) give us greater 
flexibility for corecursive definitions than non-standard semantics. 

2.4 Copatterns in dependent type theory: Reclaiming subject 
reduction 

Following the lead of the functional programming language Haskell, 
the dependently typed language Coq introduces both finite and in- 
finite trees via constructors. However, this leads to fundamental 
problems. For example, the Calculus of (Co)Inductive Construc- 
tions, the core theory underlying Coq [INRIA 2010], lacks sub- 
ject reduction. This issue is already described in Section 3.4 of 
Gimenez’ thesis [1996], Oury [2008] brought it back to the at- 
tention of the community. A detailed analysis has been given by 
McBride [2009]. 

Let us recapitulate Oury’s counterexample to subject reduction, 
as reproduced in Fig. 1 : Given a coinductive type U with construc- 
tor in that takes just an argument of type U, the (extensionally) sole 
inhabitant u of U can be constructed as the fixed point of in. The 
definitions force and eq seem “pointless” [Chlipala 2012, p. 91] 


u 

in : U -4 U 

u : U 

u = cofix in 

force : U — > U 

force = \x. case x of 

in y => in y 


a codata type 

its only (co)constructor 

an inhabitant of U 
infinite succession of ins 

extensionally, an identity 


eq : (ir : U) — ► x = force x 
eq = A*, case x of 

in y =4- refl 


eq u : u = in u 
eq u = eq u 


observation out : U — > U (same for the infinite structure u : U): 

in U ->■ U u : U 

out (in y) = y out u = u 

The equations we have written are now exactly the reduction rules, 
no restricted unfolding of cofix has to be taken into consideration. 
This makes definitional equality and, thus, type checking more per- 
spicuous, for the user it is a what-you-see-is-what-you-get equa- 
tional theory. Dependent pattern matching on coinductive types U 
is no longer available and subject reduction is restored. The “point- 
less” tricks like force and eq, necessary to deal with edges of de- 
pendent pattern matching, are also obsolete. 

While we do not develop a dependently typed language with 
copatterns in this article, we have illustrated the shortcomings of 
uniformly modeling finite and infinite data via constructors and 
highlighted the potential of copatterns in the dependently typed 
setting. 


Figure 1. Oury’s counterexample. 


but are in fact a major tool in Coq proofs about corecursive defi- 
nitions such as u since they wrap a case-distinction around a cofix 
that triggers reduction: While unrestricted reduction of cofix / to 
/ (cofix /) would diverge immediately, the following two rewrite 
equations for matching coinductive data maintain strong normal- 
ization: 


3. A Core Functional Language with Copatterns 

In this section, we introduce a core language with recursive data 
types for modeling finite data and recursive record types 2 for mod- 
eling infinite data. The term language is redex-free, which allows 
for a complete bidirectional type checking algorithm. 

We then proceed to define patterns and copatterns which allow 
us to define functions, records and programs — which can be type- 
checked by an extension of the algorithm. Function definitions will 
be modeled as sets of rewrite rules. 


case (in s) of in y =4- t = t[s/y\ 

case (cofix /) of in y =4- t = case (/ (cofix /)) of in y t 
Now, the closed term eq u simplifies via 

eq u = case u of in y => refl 

= case (cofix in) of in y => refl 
= case (in (cofix in)) of in y => refl 
= refl 

to the single constructor refl of propositional equality _=_ , which 
means that u and in u must be definitionally equal. Yet they are 
not, since u does not reduce to in u unless under a case distinc- 
tion. Subject reduction is lost! As Gimenez notes, subject reduc- 
tion holds only modulo an undecidable equality on types that al- 
lows unrestricted fixed-point unfolding, but this is not what can be 
implemented in proof assistants for Intensional Type Theory with 
decidable type checking. 

The culprit is that the rule for dependent matching is also avail- 
able for coinductive data, i. e., in case of U we have the rule 

rhti:U T, y:\Jht-. C(in y ) 

T b caseuof in y => t : C(u) 

The rule substitutes a constructed term in y for term u in type C, 
which may trigger reduction of case expressions in C that are not 
possible without the substitution. For instance, force (in y) reduces 
to in y, while force x does not reduce to x. This is exploited in the 
typing 1 of eq, which leads to the loss of subject reduction in the 
end. 

The deeper reason for this dilemma is that coinduction is just 
understood as constructing infinite trees; coinductive structures are 
just non-well-founded data structures in Coq. However, even in de- 
pendent type theory, infinite objects are better understood through 
their elimination rules [Granstrom 2009; Setzer 2012], i. e., obser- 
vations. Looking at Oury’s example, it seems wrong to regard in 
as a constructor. Rather, it should be defined in terms of the only 


3.1 Types 

We distinguish between positive types, 1, A x B, and pXD, and 
negative types, A — > B and vXR. This polarity assignment is 
inspired by focusing proofs in intuitionistic linear logic [Andreoli 
1992; Benton et al. 1993]. Our types 1, x, and p correspond to 
the positive connectives 1, ®, and a combination of © and least 
fixed point, resp., and they classify finite data. The types — > and v 
correspond to the negative — o and a combination of & and greatest 
fixed point, resp., and classify infinite data. Linearity will show up 
in the typing rules for patterns and copatterns, even though ordinary 
terms need not be linear. 

In terms of categorical languages [Hagino 1987; Cockett and 
Fukushima 1992], positive types are left objects or initial datatypes, 
and negative types are right objects or final datatypes. 


A,B,C::=X 

I P 
I N 


Type variable 
Positive type 
Negative type 


P 


N 

D 

R 


::= 1 
| Ax B 
| pXD 


Unit type 
Cartesian product 
Data type 


::= A— > B 
uXR 


Function type 
Record type 


::= (ci Ai | ■ • ■ | c n A n ) Variant (labeled sum) 

::= {di : Ai, . . . ,dn : A n } Record (labeled product) 


Figure 2. Types. 

Figure 2 introduces positive types P, negative types N, and 
types A which can be either positive or negative. Variants D serve 


1 Since refl : in y = force (in y). by dependent pattern matching 

case x of in y => refl : x = force x, thus, eq x : x = force x. 


- Our terminology should not be confused with recursive records in object- 
oriented language foundations, e. g., by Abadi and Cardelli [1994], 


to construct possibly recursive data types pXD , and records R list 
the fields di of a possibly recursive record type uXR. 

In our non-polymorphic calculus, type variables X only serve 
to construct recursive data types and recursive record types. As 
usual, pXD (uXR, resp.) binds type variable A' in D ( R , resp.). 
Capture-avoiding substitution of type C for variable A' in type A 
is denoted by A[C / X\. The set FTV(A) of free type variables of 
a type expression A is defined in the standard way. A type is well- 
formed if it has no free type variables; in the following, we assume 
that all types are well-formed. 


Datatypes Datatypes C = pXD for D = (ci A\ \ ■ ■ ■ \ c n A n ) 
are recursive variant types. They could be called algebraic types. 
We write D Ci for Ai. The constructor Ci of C takes an arguments 
of type Ai\C/X], i.e., D Ci [C / X\. Non-recursive data types can 
be represented by a void /r-abstraction p_D. Like in SML. a con- 
structor that requires no argument formally takes an argument of 
the unit type 1. Examples: 


List A 
Nat 

Maybe A 
0 


pX (nil 1 | cons (A x X)} 

pX (zero 1 | sue X) 

p_ (nothing 1 | just A) 

p_ () (positive empty type) 


Record types Record types C = uXR with R = {d\ : 

Ai, ... ,d n : A n } are recursive labeled products. They could be 
called coalgebraic types. The destructor di, if applied to a record 
of type C, returns the ith Held which has type Ai[C / A], or, with 
a “ Rd ” notation, R di [C/A']. The destructors are applied in postfix 
notation to a term t as t.di. As for data, non-recursive record types 
are encoded by a void i'-abstraction v_R. Examples: 


Stream A = 
Colist A = 
Vector A = 
T = 


uX{head : A, tail : X} 
vX{out : /r_(nil 1 | cons (A x A)}} 
^-{length : Nat, elems : List A} 
o_{} (negative unit type) 


Both D and R can be seen as finite maps from a set of labels 
(constructors and destructors, resp.) to types, with application writ- 
ten D c and Rd. We write c £ D and d £ R to express that a label 
is in the domain of the corresponding finite map. 

In this article, both pXD and uXR are just recursive types 
rather than inductive and coinductive types resp. Since D and R 
are not checked for functoriality and programs are not checked 
for termination or productivity, resp., there are no conditions that 
ensure pXD to be a least fixed-point inhabited only by finite data, 
and vXR to be a greatest fixed-point that hosts infinite objects 
which are productive. However, we keep the notational distinction 
to allude to the intended interpretation as least and greatest fixed- 
points in a total setting. 


3.2 Terms and typing 

Next we describe terms which constitute the targets of our rewrite 
rules. Terms are given by the following grammar: 


/ 

Defined symbol (e.g. function) 

X 

Variable 

0 

Unit (empty tuple) 

(£ 1 , £ 2 ) 

Pair 

c t 

Constructor application 

ft £2 

Application 

t.d 

Destructor application 


Terms can be identifiers (variable x, defined symbol /), introduc- 
tions (tuple (), (£i , £ 2 ), constructed term c £) of positive types (1, 
Ax B, pXD), or eliminations (application £1 £ 2 , projection t.d) of 
negative types (A — > B, uXR). Constructor applications choose a 
variant and fold the recursive type; destructor applications unfold 
the recursive type and select a component of the record. Missing, 


by intention, are eliminations for positive types like tuple projec- 
tions and case ; these are replaced by pattern matching. Dually, we 
omit introductions for negative types, such as A-abstractions and 
record values; instead we have definitions by copattern matching 
(see 3.4). 


A h t : A In context A, term t can be assigned type A. 


A(x) = A 
Ah x : A 


Tvar 


Ah/: S (/) 


Tfu, 


A h () : 1 


Tum 


Ah t: D c [pXD/X] 


Tcoi 


Ah t: vXR 


Ahct: pXD Ahti: R d [vXR/X] 

A h t\ : Ai — y A2 A h £2 : Ai 


TDest 


A h fi £2 : A2 
A h fi : Ai A h t 2 ■ A 2 
A h (£1 , £ 2 ) : Ai X A 2 


lApp 


Tpair 


Figure 3. Typing rules for terms. 


Typing Contexts T and A denote finite maps from term variables 
to well-formed types. To ensure linearity in pattern typing, we 
write A, A' for the disjoint union of finite maps A and A', i. e., 
dom(A) IT dom(A') = 0. We write • or simply nothing for a finite 
map with empty domain, and we usually drop the braces when 
giving a context explicitly as set of pairs {*1 : Ai, . . . , x„ : A n }. 
We assume a global signature E which maps defined symbols / to 
their type. 

The rules for the typing judgement A h t : A are given in 
Figure 3. Note that, since we have no binder on the term level — no 
A, in particular — , A remains fixed in all the rules. Assumptions 
in A describe the type of pattern variables occurring on the left 
hand side of a rule and are synthesized when analyzing copatterns. 
For each term constructor there is exactly one typing rule, so we 
trivially obtain the usual inversion lemmata. 

In the following, whenever we have a judgement J (e.g. a typing 


judgement), we write T> :: J \ to indicate that T> is a derivation of 
J using the rules for ,J . Usually our proof proceeds by induction 
on a derivation of our judgement and we write in this case “by 
induction on T>”. Some of our judgements are algorithmic, i. e., 
partial functional relations. Unless stated otherwise, all arguments 
to these relations are inputs. 


Bidirectional Type Checking Our language naturally supports 
overloading of constructors and destructors, when employing a 
bidirectional type checking algorithm [Pierce and Turner 1998], 
Supporting overloading is convenient in practice and leads to el- 
egant, compact and readable code. With bidirectional checking, 
overloading comes for free since a constructor c gets its meaning 
in the context of a data type — to type check a constructed term 
ct we push its type pXD in. Dually, a destructor d only has a 
meaning in the context of a record type uXR, which is inferred 
from head t in the projection term t.d. Overloading projections is 
standard in object-oriented programming (here, projections corre- 
spond to method calls), and has contributed to the success of the 
00 paradigm. Constructor overloading is also emerging, e. g., in 
the dependently typed languages Agda [Norell 2007] and Epigram 
[McBride and McKinna 2004], 

Given a typing context A, we infer the type A of identifiers 
and eliminations (judgement A h t => A), while we check 
introductions against a given type A (judgement A F t <= A). The 


A h t => A In context A, the type of term t is inferred as A. 

A(x) = A 


Ah f=> E (/) TCFun Ahi^i 
A h ti => A\ — > A 2 A h t2 <= Ai 


TCval 


A h fi f2 =h A 2 

A h t => I/A'fl 
A h t.d => R d [vXR/X] 


TCa p1 


TCoes, 


A 


A h t : 


In context A, term t checks against type A. 

D c [pX D / X] 


Aht 


A A = C Aht 

1 J 1 rp/l 

A '—Switch 


A h () 


c 

- TC™ 


Ahcf<= p, X D 

A h fl <= Al A h t2 4 = A 2 
A h (ti , £ 2 ) Ai X A 2 


TCconstr 

TCpair 


Figure 4. Type-checking rules for terms. 


rules are given in Figure 4. Type checking is trivially sound, but it is 
also complete without the need for any additional type annotations. 

THEOREM 1 (Soundness of type checking). 

1. IfV :: A ht=^T then A h t : A. 

2. IfV :: A h t <= A then A h t : A. 

Proof. Simultaneously by induction on the derivation V. □ 
For simply-typed lambda-calculus, bidirectional type checking 
is not complete and typically requires type annotations. It fails for 
redexes (A xt) u, since the type of a A is not inferred. In our case, 
since for a type we have either introduction or elimination, we 
lack the usual redexes, thus, bidirectional type checking is actually 
complete. 

THEOREM 2 (Completeness of type checking). IfV :: A h t : A 
then A h t <= A, and if A is a negative type, then A h t => A. 

Proof. By induction on V. Note that a proof of A h t A is 
sufficient, since this trivially implies A h t 4= A by TCswitch- □ 


3.3 Patterns and copatterns 

The driving force behind computation in our language is pattern 
and copattem matching. Pattern matching allows us to compensate 
for the missing eliminations for positive types, while copattern 
matching compensates for the missing introductions for negative 
types. In the following, we present (co)patterns and their typing. 


Patterns 


p x 

I 0 

(Pl,P2) 

cp 

Copatterns 

q ::= ■ 

qp 

q.d 


Variable pattern 
Unit pattern 
Pair pattern 
Constructor pattern 


Hole 

Application copattern 
Destructor copattern 


The postfix application of a projection d in q.d corresponds to the 
prefix application d q we used in the introduction, to conform with 
Haskell and Agda syntax. Note that, in contrast to convention in 
the ML dialects, projection does not bind stronger than application, 
i. e., f x .d is to be read (/ x).d. Our style saves parentheses when 
writing nested copatterns. 


Pattern typing is defined in Figure 5. It computes a context A 
containing all the variables in the pattern. A (co)pattern p (or q) 
must be linear, that is, each variable in A appears exactly once in 
p (or q, resp.). Again, there are two modes for pattern typing. The 
checking mode, denoted by A h p <= A, works on patterns p and 
follows the checking mode for regular typing. The inference mode, 
denoted by A | A h q => C works on copatterns q and additionally 
computes its type C from the given type A of the hole. 


Ah p <= A 


Pattern p checks against type A, yielding A. 

Ah p<= D c [pXD/XJ 


X : A h x <= A 

PCunit 


PC Vi 


1-0 


1 


A h cp <= pXD 
A\ h pi 4 = A\ A2 h P2 4 = A2 
Ai, A2 h (pi,p2) <= Ai x A2 


PCconst 

PCl'an 


A | A hij=>C 


Ah ■ => A 
Ai | A h q 


Copattem q eliminates given type A into 
inferred type C, yielding context A. 

A|4hg=^ vXR 

PCtiead . ' : „ r — — PC D e S 


A | Ah q.d=> R d [uXR/X] 
B — > C A 2 h p <= B 


Ai , A 2 | A h q p =y C 


PC A p, 


Figure 5. Type checking for patterns and rewrite rules. 

Again, there is a one-to-one connection between pattern con- 
structors and pattern typing rules. A standard inversion lemma 
holds for all rules in Figure 5. 

3.4 Programs 

A program V ::= (E, Rules) consists of a signature E mapping 
defined symbols / to their types and a collection Rules of rewrite 
rules. For each symbol / defined in the signature, Rules)/) gives 
the rewrite rules for / as a set of pairs (q i-» e), called observations, 
which define the behavior of /. We require a dedicated symbol 
main € E, called the entry point, that determines the value of a 
program. Execution of a program means rewriting main with the 
Rules until no more rewriting is possible. 

The informal syntax used in the introduction can be mechani- 
cally transformed into programs of form V . For instance, the def- 
inition fib of the stream of Fibonacci numbers corresponds to the 
following entries in E and Rules. 

E(fib) = t 2 .V{head : pY (zero 1 | sue Y) , tail : A'} 

{ ■ .head >->■ zero () 1 

■ .tail .head sue (zero ()) > 

■ .tail .tail i-» zipWith fib (fib .tail) J 

A complete program needs also entries for zipWith and _+_, and 
a symbol main. The type of main should be positive, otherwise the 
result of the program is an unprintable infinite object. Here, main 
could be a function listing the first 42 elements of the Fibonacci 
stream — we leave the details to the imagination of the reader. 

A program V is well-typed if h V as given in Figure 6, which 
in essence says that any rule (q 1 — > u ) for any defined symbol / 
must be well-typed. A first result, proven in the next section, is that 
during the execution of a well-typed program we never encounter a 
term which is ill-typed. 

4. Evaluation and Type Preservation 

In this section, we define program evaluation in terms of a small- 
step reduction relation. To decide whether a rewrite rule can fire, 


h q[f] u Check rewrite rule. 


A | E(/) h q=> C Ah u <= C 


hV 


h q[f] i ^ u 
Check program. 


TCRule 


main £ S V/ € E, (q i-a u) £ Rules(/). h </[/] ha u 
h (E, Rules) 


TCp r » 


Figure 6. Well-typed rules and programs. 


we match evaluation contexts against copattems. We prove that 
reduction preserves types. 

4.1 Evaluation contexts 

Evaluation contexts E are elimination terms with a hole in head 
position. They generalize copattems q in that they allow arbitrary 
terms e instead of just patterns p in argument positions. 

E ::= • Hole 

E e Application 

E.d Projection 

The hole ■ can be considered as a special variable. We write E[t\ 
as shorthand for E[t/-]. Typing A | T h E : C for evaluation 
context E is defined in Figure 7. This judgement holds iff A, x : 
A h E[ x] : C for a fresh variable x A. Well-typed evaluation 
contexts compose. 

Lemma 3 (Composition of contexts). If T> :: T | A h Ei : B and 
£ :: T | B h E 2 : C, then V \ A h E 2 [E 1 []\ : C. 


A I Ah E : C 


In context A, evaluation context E eliminates 
type A into type C. 

r I A h E : vXR 


ETHead 


T | A h ■ : A r I A h E.d : R d [uXR/X] 

T | A h E : B -> C T h e : B 

— ETa pp 


ETdci 


T I A h Ee : C 


Figure 7. Typing rules for evaluation context. 


4.2 Pattern matching 

Matching a term t against a pattern p, if successful, yields a sub- 
stitution a such that p[a] = t. Pattern matching is defined in terms 
of a judgement t = ! p \ a whose rules appear in Figure 8. 
Herein, a substitution a is a finite map from variables to terms; 
we write ■ for the empty map, t/x for the singleton mapping x to 
t and a, o' for the disjoint union of two maps a and a' . Substitu- 
tion typing T h a : A simply means that for all a; £ A, we have 
T h a(x) : A(x). 

While matching patterns p is standard, matching copatterns q 
is straightforward as well. The hole ■ serves as “anchor” and in an 
implementation it seems wise to match “inside-out”, i. e., start at 
the hole and proceed outwards. 


4.3 Reduction and type preservation 

The only source of computation in our language is a defined func- 
tion symbol / in an evaluation context E that matches the copattern 


t = ' P ' 


Term t matches with pattern p under substitution a. 

t = ? p\ a 


t =' x \ t/x 


PMvar 


ct =' cp \ a 


PMconstr 


0 = ? 0 \ 


PMu„ 


t i =' pi \ a i t 2 =' p 2 


: 


(tl,t 2 ) - (Pl i P2 ) \ 0-1,02 


PMpai 


E= ? q 


Evaluation context E matches copattern q re- 
turning substitution a. 


PMHead 


E = ? q\ a 


E.d =' q.d \ a 
E =' q\& t= ? p x 


PMdk 


E t = ? q p \, a, a 1 


PMa„, 


Figure 8. Rules for pattern matching. 


q of one of the rules (q t— > u) £ Rules(/). Such an e = E[f] is 
a redex which can be contracted to another expression e ! , written 

The precise rule for contraction is: 


E = ? q\ o 
E[f] i-A u[a\ 


(q i-A u) £ Rules(/) 


One step reduction e — > e! is defined as the compatible closure 
of contraction, i. e., e reduces to e' if e! results from contraction 
of one redex in e. We omit the standard inductive definition of 

e — > e! . 

Our first major result is that reduction preserves types. We 
assume a well-typed program, i. e. all rewrite rules are well-typed. 


THEOREM 4 (Subject reduction). If T h e : A and e — > e! then 
T h e' : A 


Subject reduction is a consequence of the following statements: 
Substitution preserves types, (co)pattem matching yields a well- 
typed substitution, and contraction preserves types. 

Lemma 5 (Substitution). IfV :: A h u : C and £ :: T h o : A 
then T :: T h u[o] : C for some T. 

Proof. By induction on V. □ 


Lemma 6 (Adequacy of pattern matching). IfV :: A h p <= A 
and £ : : L h e : A and T :: e = ' p a then V o : A. 


Proof. By induction on T . 


□ 


Lemma 7 (Adequacy of copattern matching). 

If V :: A \ A \~ q => C and £ w Y \ A E : B and 
T : : E =' q a then C = B and T h <j : A. 

Proof. By induction on T . □ 

Lemma 8 (Correctness of contraction). IfY \ E (/) h E : C and 
L q[f] i-» u and E = ? q \ cr then T h w[cr] : C. 

Proof. By assumption, we have 

Vi V 2 

T> :: A\ E(/) h q => B A h u 4= B 
h q[f] i-A u 

since it is the only rule that could have been used. 


By Lemma 7, using V\ and both assumptions we have that 
C = B and r h a : A. Then, by Substitution (Lemma 5) and 
V 2 , we conclude that r h «[cr] : C. □ 

Finally, the subject reduction theorem follows: 

Proof of Theorem 4. By induction on the reduction relation, with 
contraction being the only interesting case: 

T h E[f] : B and E =' g ^ ^ (q ^ u ) € Rules(/) 
E[f] n- u[a] 

By well-typedness h q[f ] >-7 u, we obtain from Lemma 8 that 

rV u[a\ : B. □ 


2. IfT \~ v v : Ai x A 2 then v = ( vi,V 2 ), T vi : Ai and 
T \~ v V2 ■ A2. 

3. If r u : pXD then v = c v' for some c £ D and 
n-ti': D c [pXD/X], 

We dualize the notion of value for terms to evaluation contexts, 
introducing a judgement A | A h„ E : C (see Figure 10). It 
accepts those well-typed evaluation contexts E that have values in 
all argument positions. The idea is that if E is “long enough”, i. e., 
if C is a positive type, then E[f] is a redex because one of the 
defining copatterns for / has to match E. This would not necessary 
be the case if the arguments in E were not values. 


5. Copattern Coverage and Progress 

A fundamental property of strongly typed languages is type sound- 
ness ; in the words of Milner [1978] “well-typed programs do not 
go wrong”. This means that well-typed programs either produce a 
value or run forever, but never get stuck by encountering an invalid 
operation, like adding a function to a string or calling a number as 
one would call a function. For our language, there are three reasons 
why a program is stuck, i. e., no reduction step is possible yet we 
have not reached a printable value: 

1. Missing rule. We might have defined a function / : Nat — > A 
but only given a rewrite rule / zero >-7 .... In this case, 
/ (sue n) is stuck. In this section, we give rules for copattern 
coverage that ensure no rewrite rules are forgotten. 

2. Ill-typed term. The term / nil is stuck even if we have given a 
complete implementation of / : Nat — > A. However, ill-typed 
terms like / nil are already excluded by type checking and the 
type preservation theorem. 

3. Infinite object. The term / does not evaluate by itself; it is an un- 
derapplied function. However, just as the typical interpreter, we 
consider terms of negative types as values. As a consequence, 
our notion of value is not syntactic, but type-dependent. 

As main technical result of this section and the article, we 
prove type soundness, syntactically [Wright and Felleisen 1994], 
by showing the progress theorem for a call-by-value strategy. 


A | A h„ E : C 


E is an evaluation context with only values in 
application arguments. 


T\A\- V E\ vXR 

r I A h v ■ : A EVliead r I A K E.d : R d [uXR/X] 


EVoest 


T\A\- V E:B->C r h„ v : B 
r I A h„ E v : C 


EVapp 


Figure 10. Rules for value evaluation contexts. 

The following two propositions enable us to analyze non-empty 
value evaluation contexts from the inside out; they will be used in 
Theorem 12. 

Lemma 1 0 (Splitting a function evaluation context). 

IfV :: T | B — t C \~ v E : A and E 7 ^ • then E = E'[- d] with 
T K v : B and T \ C \~ v E' : A. 

Proof. By induction on V. □ 

Lemma 1 1 (Splitting a record evaluation context). 

IfV :: T | uXR h v E : A and E 7 ^ ■ then E = E'[-.d\ with 
r I R d [uXR/X] h„ E' : A. 

Proof. By induction on V. □ 


5.1 Values and evaluation contexts 

Values are defined using a new judgment A h„ e : A to mean that 
the expression e is a value of type A under the context A. We also 
use v to denote an expression which acts as a value. Whether an 
expression is considered a value or not depends also on its type, 
in particular, each expression of negative type N is considered a 
value — the rules are given in Figure 9. 


Ah v e : A 


In context A, e is a value of type A. 


r h x : A 
F h„ x : A 


Vvar 


n-„»: D c [pXD/X ] 
F h„ c v : p,XD 


V Const 


r h„ () : 1 


V Unit 


r h„ Vi : Ai r h„ V2 : A2 

T h„ (v!,v 2 ) ■ Ar x A 2 


F h e : N 
r h v e:N 


V \Jcg 


Figure 9. Rules for values. 


Lemma 9 (Inversion for values). The following hold for v x. 
1. IfT \~ v v : 1 then v = (). 


5.2 Coverage 

Figure 1 1 defines a judgment to indicate that a list of copattems 
covers all eliminations of a given type A. The judgment is A < 
| (A h q =£- C) or, more generally, A < \ Q where Q = (A, h 
q t => is a set of non-overlapping copattems q; with 

their type Ci and context Ai, each satisfying Aj | A h qi => Ci. 

The mles to construct a covering set of copatterns are not 
syntax-directed. To check whether a given set of copatterns Q for a 
type A is complete, we non-deterministically guess the derivation 
of A <3 1 Q, if it exists. Although this NP-algorithm is not the best 
we can do, we are confident that we can adopt existing efficient 
coverage algorithms [Norell 2007] for our language. 

The initial covering is given by the axiom CHoie- We can refine 
a covering Q by focusing on one copattern Q and either split the 
result of negative type or split one of its variables of positive type. 
Result splitting at function type B — > C applies the copattem 
q to a fresh variable x : B, at record type vXR we take all 
projections ( q.d)d£R ■ Splitting a variable x replaces it by unit (), a 
pair (xi, X2) or all possible constructors (c x') c eD, in accordance 
with the type 1, Ai x A 2 , or p,XD of the variable. 

Let us revisit the example of the function cycleNats from the 
introduction and walk through the rules for coverage. With the 
following shorthands for types 

Nat = p.X (zero 1 | sue X) 

StreamNat = zz.Y{head : Nat, tail : X}, 


A < | Q Typed copatterns Q cover elimination of type A. 
Result splitting: 




CHole ' 


A <\ Q (A \- q =$■ B ^ C) 


> A) A < | Q (A, x : B b q x => C) 
A < | Q (A I- q => vXR) 


Ca P | 


A < | Q (A b q.d => R d [uXR/X]) deR 

Variable splitting: 

A < | Q (A, x : 1 b q => C) 

* Cuni 

A <i | Q (A b g[()/a;] =>■ C) 

A < 1 1 Q (A, a: : Ai x A 2 b g => C) 


C D e 5 


A < | Q (A, n : Ar, a; 2 : A 2 b g[(*i, X2)/x\ => C ) 


C Pair 


fton there are A , A such that E — A [A [•]], A = ? g; \ cr for 
some i, ■ \ A b„ E 2 : C% and ■ \ Ci b„ A : P. 

To prove this theorem, we use the following statements. 

Lemma 13 (Splitting a pattern variable). 

Let I? :: A, a; : .A | B b g => C and E :: | B b„ E : C and 
T :: E= 7 q\o. 

1. Assume A = Ai x A 2 and let q' = q[(xi, xf)/x\. Then 
A,*i : A i,X 2 : A 2 | B b q' =>■ C and E =' q' \ o' 
with o = o'[x i-A (o'(x\), cr'(x 2 ))]. 

2. Assume A = fjtXD and let q' = q[c x' /x\ for some c G D. 
Then A, x' : D c [^iX D/X] b q =>■ C and E = ? q' \ ct' wif/7 
a = a' [a; i-A c <r'(a;')]. 

3. Assume A = 1 mzrf to g' = q[()/x\. Then A b q 4 = C and 
E = ? g' \ cr' wif/i <r = cr' [a; 1 — >■ ()]. 

Proof. First, prove an adaptation of these statements for patterns 
p and values v instead of copattems g and evaluation contexts E. 
Then, prove this lemma by induction on T . □ 


A < | Q (A, x : pXD b g => C) 

A < | Q (A, a:' : b gfcab/a;] => C) c6D 


Figure 11. Rules for copattem coverage. 


the signature entries for cycleNats are the following: 

E(cycleNats) = Nat — > StreamNat 

{ • x .head 1 — >■ a; j 

• (zero ()) .tail i-a cycleNats N > 

■ (sue x) .tail ha cycleNats a; J 

To check coverage, we start with the trivial covering and succes- 
sively apply the rules until we obtain the copatterns of cycleNats. 
Since A = Nat — > StreamNat stays fixed throughout the deriva- 
tion, we omit it and just write the copattem list Q. We start with 
CHole. 

(• b • => Nat —¥ StreamNat) 

We apply x to the hole by Ca pp - 

(a: : Nat b ■ x => StreamNat). 

Then we split the result by CDest- 

(a: : Nat b ■ x .head => Nat) 

( x : Nat b • x .tail => StreamNat) 

In the second copattem we split x via Cconst, reusing the variable 
name x. 

( x : Nat b • x .head Nat) 

{x : 1 b • (zero x) .tail =*> StreamNat) 

(x : Nat b • (sue a:) .tail =*> StreamNat). 

Finally, we apply Cunit, replacing a; by (). 

( x : Nat b ■ x .head => Nat) 

(■ b • (zero ()) .tail => StreamNat) 

(x : Nat b • (sue a;) .tail => StreamNat) 

The lists of copatterns q for type A generated by the splitting 
rules is complete in the sense that every closed value context E 
eliminating A into a positive type P actually matches one of the 
copatterns qi. 

THEOREM 12 (Matching with a covering copattern). 

IfV • | A b„ E : P and E :: A <1 | (A; b qi =£■ Ci)i=i. .n, 


Proof of Theorem 12. The theorem is proved by induction on 
the coverage derivation E. The variable splitting cases Cp a i r , Cconst, 
and Cunit follow from Lemma 13. We consider the rules for result 
splitting. 

A <\Q(Ah q^ B^C) 

c- . . — 

A <\Q (A, i:Bbgi=!> C)i= 

By induction hypothesis, the statement holds for one of the patterns 
in Q (A b g =^> B — > C). If the pattern has been chosen from 
Q, we are done. Thus, without loss of generality, E = .Ei[i? 2 [']] 
and ■ j A b„ E 2 : B — > C and • | B — > C b„ E\ : P and 
E2 = ? q \ o. 

If Ei = ■ then P = B — » C, which is a contradiction since P 
is a positive type. If A ■, then E\ = E\ [■ u] with ■ b v v : B 
and ■ | C b„ E[ : P by Lemma 10. 

Thus, let E’ 2 = Eo v and ■ | A b„ E’ 2 : C by EVa pp , and 
E 2 =' qx\o, v/xby PM ApP . 

Case £ - ^ < I Q (A b g ^ uXR) 

" A < 1 1 Q (A b q.d => R d [uXR/X]) deR 
Analogously, using Lemma 11. □ 

5.3 Progress 

We are ready to show that evaluation of a well-typed program does 
not get stuck, provided that all definitions come with a complete set 
of observations. First we note that closed terms are either values or 
eliminations of a defined symbols. Such an elimination is either a 
value evaluation context or contains a closed non-value. 

Lemma 14 (Decomposition). If ■ b e : A then either 

1. e = (), A = 1, 

2. e. — (ei, e 2 ), A = Ai x A 2 , 

3. e = ce! ,A = fiXD, 

4. e = E 2 [E 1 [f] e'] where ■ \ E (/) b„ A : B ->• C and 
■ | C b E 2 : A and \f v e! : B for some f, some evaluation 
contexts E 1 , A. some term e! and some types B , C. 

J. e = E[f] for some f, E with ■ \ E (/) b„ E : A. 

Proof. By induction on e. We only show the cases e = ei e 2 and 
e = e! .d. The other cases are trivial. 

Case b ei e 2 : A. Then by inversion b ei : B —y A and 
b e 2 : B. By induction hypothesis ei = E[f] with - | E (/) b„ E : 
B — > A for some /, E or ei = A[A[/] e!\ for some /, A, A, 


and e' where ■ | £(/) K Ei : B' ->• C", • | C' h B 2 : B -»■ A 
and !/.„ e ; : B', as the 3 other cases are impossible. In the former 
case, if l/„ e 2 : B , we can obtain case 4 by letting E 2 = ■, E = Ei 
and e 2 = e'. This gives us ei e 2 = -[E[f] e 2 ]. If e 2 : B, 
then, by EVa pp , ■ | £(/) E[f] e 2 : A and B' = E e 2 - In 
the latter case, we have E 2 [Bi [/] e!) ei = B£ [Bi [/] e!\ by setting 
E'2 = E2 & 2 - 

Case h e.d : A. Then by inversion, b e : vXR for some R. 
By induction hypothesis, e = E[f] and ■ | £(/) b„ E : vXR, 
or e = E 2 [Ei [/] e!\ where e' is not a value. In the former case, 
e.d = E[f].d = E'[f] and ■ | £(/) h„ E.d : R d [uXR/X] by 
EVoest- Otherwise, e.d = E 2 [Ei[f] e'].d = E' 2 {Ei{f] e']. □ 

Finally we prove progress under the assumption that every def- 
inition / is complete, written £(/) <1 1 Rules(/). 

THEOREM 15 (Progress). lfT> :: h e : A then either b v e : A or 
e — > e' for some e . 

Proof. The proof is done by induction on e. By Lemma 14, we 
have live possible cases. Since the four first cases follow by a 
simple induction argument, we only present the last case. 

Here e = E[f] and ■ | £(/) b„ E : A. If A is negative, 
then e is already considered a value and we are done. Otherwise, 
since by assumption £(/) < 1 1 Rules(/), we can apply Theorem 12 
and obtain Ei,E 2 such that E = E\ [E 2 [•]], E 2 =' qt \ a 
for some qi £ Rules(/), plus • | £(/) b E 2 : C, and ■ 

Ci h„ Ei : A. Thus, by our reduction rules E 2 [f] h-> Ui[a] 
where (q r , u r ) £ Rules)/) and so E 2 [f] — >■ Ui[a]. We conclude 
that Ei[E 2 [f[] ^ Ei[ Ui [o]}. □ 

6. Extensions and Implementations 

Our core language misses introduction rules for functions and ob- 
jects, thus, we do not have lambda abstractions or record expres- 
sions. However, we can embed sets of behaviors {q u} into 
the expression syntax and obtain anonymous objects that subsume 
A abstractions, SML’s anonymous functions defined by pattern 
matching, and record expressions: 

A xt = 

fn nil => false 

| cons x xs =y true 

record{fst = G; snd = t 2 } = 

Of course, bidirectional type checking is no longer complete since 
anonymous objects can only be checked against a given type, but 
can appear in elimination position. 

Copattems have been added to the development version’ of 
Agda [Agda team 2012], Currently, projection copatterns are not 
part of the core of Agda, they are parsed but then translated into 
record expressions. This does not give the full flexibility of copat- 
terns, but allows us to experiment with them. Full copatterns in the 
core would allow us to exploit the benefits of deep projection co- 
patterns and mixed projection/application copatterns, but for that, 
Agda’s coverage checker has to be extended to copatterns. To ac- 
complish this, further research is required, because dependent pat- 
tern matching is a far from trivial enterprise [Coquand 1992; Schiir- 
mann and Pfenning 2003; Goguen et al. 2006; Norell 2007; Dun- 
field and Pientka 2009]. 

Another prototypical implementation of copatterns exists in 
MiniAgda [Abel 2012], In MiniAgda, one can certify termination 
and productivity using sized types [Hughes et al. 1996; Barthe et al. 
2004; Abel 2007]. Copatterns provide the right syntax to decorate 
corecursive definitions with size variables that witness productivity. 


3 Available from the dares repository http : / /code . haskell . org/Agda. 


7. Related Work 

Our work builds on the insight that finite datatypes correspond 
to initial algebras and infinite datatypes correspond to final co- 
algebras. This was first observed by Hagino [1989] and was the ba- 
sis of categorical programming languages such as symML [Hagino 
1987] and Charity [Cockett and Fukushima 1992]. Categorical pro- 
gramming languages typically support programming with the mor- 
phisms of category theory; while they do provide iteration, they do 
not support general recursion and pattern matching. In Charity, sup- 
port for pattern matching on data types was added [Tuckey 1997], 
but it lacks support for copattern matching. 

Our type theoretic development of copattems exploits the dual- 
ity of positive and negative types which is well known in focused 
proofs [Andreoli 1992], Previously, focusing has been applied to 
pattern matching [Zeilberger 2008a; Krishnaswami 2009] and eval- 
uation order [Zeilberger 2009; Curien and Herbelin 2000]. Clos- 
est to our work from a theoretical point of view is the work by 
Licata, Zeilberger and Harper [2008] where a language based on 
the sequent calculus is described which supports mixing LF types 
with computation-level types. The weak representational function 
space of LF is classified as a positive connective and admits pat- 
tern matching using constructor patterns; the strong computation 
level function space is classified as negative connective which is 
defined by destmetor patterns. The accompanying technical report 
also describes briefly how to add ^-formulas to the proposed sys- 
tem. However, in their work, (co)pattem matching happens at the 
meta level ; this is like replacing induction by an ut-rule. Our work 
provides an object-level syntax for copatterns and an algorithm for 
copattern coverage. 

Kimura and Tatsuta [2009] extend Wadler’s [2003] Dual Cal- 
culus to inductive and coinductive types, treating the constructor 
for inductive data as value constructor and the destructor for coin- 
ductive data as continuation constructor. However, they do not in- 
troduce recursive values or recursive continuations nor pattern and 
copattern matching, but allow only iteration over finite data and 
coiteration into infinite data. 

Agda, in its currently released version 2.3.0, already avoids 
Coq’s subject reduction problem. Infinite objects are created via 
delay p and analyzed via force \>, the corresponding operation on 
types is lifting 00 . In spirit, this approach mimics the standard trick 
in call-by-value languages such as ML and Scheme to encode lazy 
values by suspensions, i. e., functions over the unit type. The two- 
edged dependent pattern matching on infinite objects is ruled out, 
since one cannot match on functions. 

Agda's coinduction is informally described by Danielsson and 
Altenkirch [2010], but it lacks solid theoretical backing. Indeed, 
compositionality is lost, because any data type that uses lifting 
is coinductive [Altenkirch and Danielsson 2010]. For instance, a 
data type of trees with infinite branching realized via streams host 
automatically infinitely deep trees, even if that is not expressed 
by the data type definition. Our work reinterpretes lifting as the 
generation of a mutual recursive record type that contributes the 
coinductive part to the data type. Forcing is interpreted as destructor 
and delaying as a mutual definition by destructor pattern. This 
way, we provide a standard semantics for coinduction in Agda and 
recover compositional constmction of data types. 


8. Conclusion 

In this paper, we have presented a type-safe foundation for pro- 
gramming with infinite structures via observations. We model finite 
data using variant types and infinite data via record types. Pattern 
matching of finite data is extended with its dual notion of copattem 
matching on infinite data. While we do not consider termination 



and productivity in this paper, we guarantee that the functions are 
covering, i.e., they are defined on all possible inputs. 

Copattems lay a foundation for Unitary rewriting with infinite 
objects. They are also an excellent candidate for representing core- 
cursive definitions in type-theoretic proof assistants such as Coq 
and dependently typed languages like Agda. 

In the future, we plan to extend the presented work to full 
dependent types. There are two main theoretical issues we need 
to tackle: first, extension of copattern coverage to dependent types, 
and secondly, checking termination and productivity of functions 
to guarantee strong normalization. A candidate for the latter task 
are sized types [Hughes et al. 1996; Barthe et al. 2004; Abel 
2007] as already implemented in Mini Agda [Abel 2012], Further, 
we aim at developing a denotational model for languages with 
copatterns. It seems that semantics based on orthogonality [Parigot 
1997; Vouillon and Mellies 2004] provides a good starting point for 
this investigation. 

From a practical point of view, we plan to fully integrate copat- 
terns into Agda for a perspicuous and robust foundation of coin- 
duction. 
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A. Agda Examples 

The development version of Agda has experimental support for 
copatterns which can be turned on by option --copatterns. In 
the following we present a few examples for copatterns in Agda 
syntax. 

Colists Colists have a coinductive type with an embedded variant 
type. In Agda this is represented as mutual recursion between a 
coinductive record type and a data type. 

mutual 

data pColist (A : Set) : Set where 
: pColist A 

: (x : A) (xs : vColist A) -* pColist A 

record vColist (A : Set) : Set where 
coinductive 
field out : pColist A 
open vColist 

Our first function lets us append a vColist to a List. It is defined by 
recursion on the list. 


open import Data. List using (List; []; map; concatMap) 
append : {A : Set} — » List A — > vColist A — t vColist A 
out (append [] ys) = out ys 

out (append (x :: xs) ys) = x :: append xs ys 

Note the overloading of constructor for lists and colists. 

We can also define a zipWith function for colists defined as a 
pair of mutually recursive functions. One is acting on vColist, the 
other acting on pColist. 

mutual 

zipWith : {A B C : Set} — ¥ (A — > B — > C) — ¥ 
vColist A — ¥ vColist B — ¥ vColist C 
out (zipWith f xs ys) = zipWithp f (out xs) (out ys) 

zipWithp : {A B C : Set} — ¥ (A — ¥ B — ¥ C) — >■ 
pColist A — ¥ pColist B — ¥ pColist C 
zipWithgt f [ ] ys = [] 

zipWithp f (x :: xs) [] = [] 

zipWithp f (x :: xs) (y :: ys) = (f x y) :: (zipWith f xs ys) 

Another example is an unfold function. Suppose we have a set 

of states S and a set of values A corresponding to the observation 
we do at some particular state. Then, given a function taking a 
current state and outputting a new state and its value, or no state 
at all if it is a terminal state, and given an initial state, we can build 
a colist of values of all states visited. 

open import Data. Maybe using (Maybe; nothing; just) 
open import Data. Product using (_x_; ) 

mutual 

unfold : {A S : Set} — ¥ (S — ¥ Maybe (A x S)) — ¥ S — ¥ 
vColist A 

out (unfold f s) = unfoldp f(fs) 
unfoldp : {A S : Set} — ¥ (S — ¥ Maybe (A x S)) — ¥ 
Maybe (A x S) — ¥ pColist A 
unfoldp f (just (a, s)) = a:: unfold fs 
unfoldp f nothing = [ 

Breadth-first traversal of non-wellfounded tree Finitely branch- 
ing but potentially infinitely deep trees can be represented by a 
coinductive record with two fields, a label and a list subs of sub- 
trees. 

record vTree (A : Set) : Set where 
coinductive 
field label : A 

subs : List (vTree A) 
open vTree 

If we have a forest List (vTree A), we can extract the labels in 
a breadth-first manner by first taking all the roots, then concate- 
nateting all the subtrees and recurse. To ensure productivity, we 
distinguish the empty forest from the non-empty forest. 

bf : {A : Set} — ¥ List (vTree A) — V vColist A 

out (bf []) = [] 

out (bf (t :: ts)) = label t :: 

append (map label ts) 

(bf (concatMap subs (t :: ts))) 

bf is productive since it is guarded-by-constructors [Coquand 
1993]: it directly outputs either the empty colist or the non-empty 
colist, and since append xs ys only adds elements in front of ys. 
The latter is not yet tracked by Agda’s termination and productivity 
checker, thus, the termination checker rejects this code. Productiv- 
ity checking using sized types, as realized in MiniAgda, does work 


for bf, and it is our goal to bring coinduction in Agda to the same 
level of expressiveness as in MiniAgda. 



